FIG. 1 illustrates a protocol stack architecture of an IEEE 802.16 interface. Referring to FIG. 1, a service-specific convergence sublayer (CS) maps or transforms external communication network data received via a CS service access point (CS SAP) into medium access control entity service data units (MAC SDUs) received by a MAC common part sublayer (MAC CPS) via a MAC SAP. This transformation or mapping includes a function of identifying SDUs (service data units) of an external communication network to correlate a corresponding MAC SFID (service flow identifier) and a CID (connection identifier). Multi-CS regulations for various protocol interfaces are provided. An inner format of a CS payload is attributed to unique features of the CS. The MAC CPS is not required for analyzing information received from the CS payload or understanding a format.
The MAC CPS provides functions for system access, bandwidth allocation, access setting, and access maintenance and management as core functions of the MAC. The MAC CPS receives data classified according to a specific MAC access method from various CSs via the MAC SAP. The MAC CPS also exchanges data, such as PHY control and statistical data, with a PHY via a PHY SAP, which is a unique implementation scheme.
IEEE 802.21 aims for the international standardization of inter-heterogeneous-network media independent handover. Specifically, IEEE 802.21 endeavors to enhance user convenience when operating mobile terminal devices by providing seamless handover and service continuity between heterogeneous networks. A media independent handover (MIH) function, an event trigger, a command service and an information service (IS) are defined as basic requirements in the IEEE 802.21 standard specification.
A mobile subscriber station in media independent handover is a multi-mode node supporting at least one interface type. An interface can be implemented in various types. For example, a wire-line type interface such as an IEEE 802.3-based Ethernet, wireless interface types based on IEEE 802.XX interfaces including IEEE 802.11, IEEE 802.15, IEEE 802.16 and the like, and interfaces defined by a cellular standardization organization such as 3GPP, 3GPP2 and the like, are possible.
An information service for inter-heterogeneous-network handover is explained as follows. First, a media independent information service (MIIS) provides a similar frame network on a hierarchical heterogeneous network to facilitate a search and selection of various kinds of present networks. Namely, the media independent information service (MIIS) provides detailed information about a network needed to search and select a network and should be accessible from any kind of networks. The media independent information service (MIIS) should include the following information elements such as link access parameter, security mechanism, neighbor map, location, provider and other access information, cost of link and the like.
Media independent handover (MIH) may be defined between IEEE 802-series interfaces or between an IEEE 802-series interface and a non-IEEE 802-series interface, such as 3GPP or 3GPP2. Furthermore, a mobility supporting protocol of an upper layer such as a mobile Internet protocol (Mobile IP) and a session initiation protocol (SIP) should be supported for the seamless handover service.
FIG. 2 is a diagram of a general MIH reference model for supporting an MIH function. Referring to FIG. 2, service access points such as MIH_MGMT_SAP, MIH_SME_SAP, MIH_USER_SAP, MIH_MAC_SAP, MIH_PHY_SAP, LSAP and MIH_RRC_SAP exist for considering the MIH function.
The MIH_MGMT_SAP defines an interface between an MIH function layer and a management plane. MIH messages can be used for communications between peer MIH entities. MIH messages based on a management frame can be also sent unauthorized. The MIH_MGMT_SAP also defines primitives used for Media Independent Event Services, Media Independent Command Services and Media Independent Information Services.
The MIH_SME_SAP defines an interface between an MIH function layer and a station management entity (SME) defined by IEEE 802.11 or a network control and management system (NCMS) defined by IEEE 802.16. The MIH_SME_SAP can be identical to the MIH_MGMT_SAP.
The MIH_USER_SAP defines an interface for communication with an upper layer or higher (IP layer, i.e., at least protocol layer 3 or higher).
The MIH_MAC_SAP defines an interface between an MIH and a medium access control layer (MAC) of each technology (IEEE 802.11, IEEE 802.16, 3G, etc.). Interfaces defined by the MIH_MAC_SAP are mainly used in transferring MAC service data units (MSDUs) between peer entities. It is unnecessary to define a new interface and primitive for the MIH_MAC_SAP. However, interfaces defined through the MIH_MAC_SAP can be used in delivering payloads based on an MIH protocol to peer MIH entities.
The MIH_PHY_SAP defines an interface between an MIH and a physical layer (PHY) of each technology (IEEE 802.11, IEEE 802.16, 3G, etc.). The MIH communicates through the PHY of the corresponding technology using MACs of the corresponding technology. It is unnecessary to define new interfaces and primitives for the MIH_PHY_SAP.
The LSAP defines an interface between the MIH and a lower link control (LLC) layer. The MIH initiates a connection to a peer LLC entity to perform communication. The LSAP can directly use an LLC interface in establishing a data path to send MSDUs through other links. It is unnecessary to define new interfaces and primitives for the LSAP. The MIH_RRC_SAP defines an interface between an MIH function and a radio resource control (RRC) layer.
Messages used in the related art are explained as follows. A dynamic service addition request (DSA-REQ) message is transferred by a mobile subscriber station or base station to create a new service flow. Table 1 shows a DSA-REQ message format.
TABLE 1SyntaxSizeNotesDSA-REQ_Message_Format( ) {Management Message Type = 11 8 bits Transaction ID16 bits TLV Encoded InformationVariableSpecific TLV }
In Table 1, a DSA-REQ message is created by a mobile subscriber station or base station and includes parameters such as a connection identifier (CID), a transaction identifier (Transaction ID), etc. The CID is included in a general MAC header and represents a Primary Management CID of a mobile subscriber station. The Transaction ID represents a unique ID of a transaction assigned by a transmitting side. All other parameters are coded as threshold limit value (TLV) tuples.
The DSA-REQ message may not include a parameter for at least one service flow. The DSA-REQ message should include parameters such as Service Flow Parameters, Convergence Sublayer Parameter Encodings and a Hash-Based Message Authentication Code (HMAC) Tuple. The Service Flow Parameters represent regulations for traffic characteristics and scheduling conditions of service flow. The Convergence Sublayer Parameter Encodings represent regulations for specific CS parameters of service flow. The HMAC Tuple includes a key-designated message digest for authorizing a transmitting side. The HMAC Tuple attribute should correspond to a last attribute in an attribute list of a DSx message.
A dynamic service addition response (DSA-RSP) message is a message generated in response to a received DSA-REQ message. Table 2 shows a DSA-RSP message format.
TABLE 2SyntaxSizeNotesDSA-RSP_Message_Format( ) {Management Message Type = 128 bits Transaction ID16 bits  Confirmation Code8 bits TLV Encoded InformationvariableSpecific TLV }
In Table 2, a DSA-RSP message includes parameters such as a CID, a Transaction ID, a Confirmation Code, etc. The CID is included in a general MAC header and represents a Primary Management CID of a mobile subscriber station. The Transaction ID is a transaction ID of a corresponding DSA-REQ and represents a unique ID of a transaction assigned by a transmitting side. The Confirmation Code corresponds to the entire DSA-REQ message and has an 8-bit length. All other parameters are coded as TLV tuples.
If a transaction is successfully performed, Service Flow Parameters and CS Parameter Encodings should be included in the DSA-RSP message. If a newly allocated CID, an extended Service Class Name or a specific parameter indication (corresponding to a case of CC=“reject-not-supported-parameter-value” or “reject-not-supported-parameter” only) causing access generation rejection is included in all regulations of a service flow, the DSA-RSP message includes all regulations of the service flow. The CS Parameter Encodings is a parameter representing regulations of specific parameters of the service flow.
If a transaction is not successfully performed, a Service Flow Error Set should be included in the DSA-RSP message. The DSA-RSP message should include the Service Flow Error Set and a service flow reference/SFID identifying function for each failed service flow. All failed specific QoS parameters of a corresponding service flow should be included in each Service Flow Error Set. The Service Flow Error Set is omitted if the entire DSA-REQ message is successfully performed.
The DSA-RSP message includes an HMAC Tuple regardless of success/failure of transaction execution. The HMAC Tuple attribute includes a key-designated message to authorize a transmitting side. The HMAC Tuple attribute should correspond to a last attribute in an attribute list of a DSx message.
A dynamic service addition acknowledgment (DSA-ACK) message is a response message to the DSA-RSP message. Table 3 shows a DSA-ACK message format.
TABLE 3SyntaxSizeNotesDSA-ACK_Message_Format( ) {Management Message Type = 138 bits Transaction ID16 bits  Confirmation Code8 bits TLV Encoded InformationvariableSpecific TLV }
In Table 3, a DSA-ACK message includes parameters such as a CID, Transaction ID, Confirmation Code, etc. The CID is included in a general MAC header and represents a Primary Management CID of a mobile subscriber station. The Transaction ID is a transaction ID of a corresponding DSA-REQ message and represents a unique ID of a transaction assigned by a transmitting side. The Confirmation Code corresponds to the entire DSA-REQ message and has an 8-bit length. All other parameters are coded as TLV tuples.
A Service Flow Error Set of the DSA-ACK message encodes specific items of service flows having failed in transmitting the DSA-RSP message. A corresponding DSA-REQ message should include a function of confirming the Service Flow Error Set and a service flow reference for all failed QoS parameters of all failed service flows. The Service Flow Error Set of the DSA-ACK message is omitted if the entire DSA-REQ message is successfully performed.
An HMAC Tuple attribute of the DSA-ACK message includes a key-designated message digest to authorize a transmitting side. The HMAC Tuple attribute should correspond to a last attribute in an attribute list of a DSx message.
Table 4 shows an included field when a mobile subscriber station transmits the DSA-REQ message. A base station receives the message and then identifies a format of a connection established by the CS through this field.
TABLE 4TypeLengthValueScope[145/146].2810: No CSDSx-1: Packet, IPv4REQ2: Packet, IPv63: Packet, 802.3/Ethernet4: Packet, 802.1Q VLAN5: Packet, IPv4 over 802.3/Ethernet6: Packet, IPv6 over 802.3/Ethernet7: Packet, IPv4 over 802.1Q VLAN8: Packet, IPv6 over 802.1Q VLAN9: ATM10: Packet, IPv4 with HeaderCompression (ROHC)11: Packet, IPv4 with HeaderCompression (ECRTP)12: Packet, IPv6 with HeaderCompression (ROHC)13: Packet, IPv6 with HeaderCompression (ECRTP)14: Packet, IPv4 over 802.3/Ethernetwith Header Compression (ROHC)15: Packet, IPv4 over 802.3/Ethernetwith Header Compression (ECRTP)16: Packet, IPv6 over 802.3/Ethernetwith Header Compression (ROHC)17: Packet, IPv6 over 802.3/Ethernetwith Header Compression (ROHC)18: Packet, IPv4 over 802.1Q VLANwith Header Compression (ROHC)19: Packet, IPv4 over 802.1Q VLANwith Header Compression (ECRTP)20: Packet, IPv6 over 802.1Q VLANwith Header Compression (ROHC)21: Packet, IPv6 over 802.1Q VLANwith Header Compression (ECRTP)22~255: reserved
Each CS defines a parameter set encoded within a sub-index with the following cst values. In case of an IP for an IEEE 802.xx interface, associated IP and IEEE 802.xx parameters are included in a DSX-REQ message. Definitions for CS and cst are shown in Table 5.
TABLE 5cstCS99ATM100Packet, IPv4101Packet, IPv6102Packet, 802.3/Ethernet103Packet, 802.1Q VLAN104Packet, IPv4 over 802.3/Ethernet105Packet, IPv6 over 802.3/Ethernet106Packet, IPv4 over 802.1Q VLAN107Packet, IPv6 over 802.1Q VLAN108Packet, IPv4 with Header Compression (ROHC)109Packet, IPv4 with Header Compression (ECRTP)110Packet, IPv6 with Header Compression (ROHC)111Packet, IPv6 with Header Compression (ECRTP)112Packet, IPv4 over 802.3/Ethernet with HeaderCompression (ROHC)113Packet, IPv4 over 802.3/Ethernet with HeaderCompression (ECRTP)114Packet, IPv6 over 802.3/Ethernet with HeaderCompression (ROHC)115Packet, IPv6 over 802.3/Ethernet with HeaderCompression (ROHC)116Packet, IPv4 over 802.1Q VLAN with HeaderCompression (ROHC)117Packet, IPv4 over 802.1Q VLAN with HeaderCompression (ECRTP)118Packet, IPv6 over 802.1Q VLAN with HeaderCompression (ROHC)119Packet, IPv6 over 802.1Q VLAN with HeaderCompression (ECRTP)
Meanwhile, the CS and primitives of a MAC_SAP for a MAC service are explained as follows.
FIG. 3 is a diagram of a signal flow for a MAC service request and response, in which a request primitive is used for an initial request of a service. Referring to FIG. 3, if the CS delivers a request primitive to a Peer MAC, the Peer MAC creates an indication primitive to deliver to an original requesting entity, i.e., the CS. The CS then creates a response primitive in response to the indication primitive and then delivers it to the Peer MAC. The MAC having received the response primitive delivers a confirmation primitive to the CS.
1) MAC_CREATE_SERVICE FLOW.request
* Function: The CS entity of a base station device (hereinafter called BS) or a subscriber device (e.g., mobile subscriber station, etc.) (hereinafter called SS) requests dynamic addition of connection.
* Semantics:
MAC_CREATE_SERVICE FLOW.request
(
MAC Address
scheduling service type,
convergence sublayer,
service flow parameters,
payload header suppression inicator,
encryption indicator,
Packing on/off indicator,
Fixed-length or variable-length SDU indicator,
SDU length (only needed for fixed-length SDU connections),
CRC request,
ARQ parameters,
sequence number
)
* Creation Timing: The present primitive is created when the CS of a BS or an SS sets a new connection in the BS.
* Effect of Receipt: In case that the present primitive is created by the SS, the SS sends a DSA-REQ message request to a MAC of the BS. On the other hand, if the present primitive is created by the BS, the BS checks the validity of the request.
2) MAC_CREATE_SERVICE FLOW.indication
* Function: The present primitive is sent by a non-initiating MAC entity. After reception of the DSA-REQ message, the present primitive is transmitted in response to the received message. If the non-initiating MAC entity lies in a BS side, an SFID and available CIDs are created and a request is authorized.
* Semantics:
MAC_CREATE_SERVICE FLOW.indication
(
service type,
convergence sublayer,
service flow parameters,
sequence number
)
* Creation Timing: Once the DSA-REQ message is received, the present primitive is created by a non-initiating side MAC.
* Effect of Receipt: The CS checks validity of the request and accepts or rejects the corresponding request through a MAC_CREATE_SERVIC FLOW.response primitive.
3) MAC_CREATE_SERVICE FLOW.response
* Function: The MAC_CREATE_SERVICE FLOW.response is created by a non-initiating MAC entity in response to the MAC_CREATE_SERVICE FLOW.indication.
* Semantics:
MAC_CREATE_SERVICE FLOW.response
(
Connection ID,
response code,
response message,
sequence number,
ARQ parameters
)
* Creation Timing: Once the MAC_CREATE_SERVICE FLOW.indication is received, the present primitive is created by a non-initiating CS.
* Effect of Receipt: The MAC sends a DSA-RSP message.
4) MAC_CREATE_SERVICE FLOW.confirmation
* Function: The MAC_CREATE_SERVICE FLOW.confirmation confirms that a convergence entity provides a requested connection.
* Semantics:
MAC_CREATE_SERVICE FLOW.confirmation
(
Connection ID,
response code,
response message,
sequence number
)
* Creation Timing: The present primitive is created by an initiating MAC entity when a DSA-RSP message is received.
* Effect of Receipt: It is confirmed that a convergence entity functions as a connection requested for a transmission request.
5) MAC_CHANGE_SERVICE FLOW.request
6) MAC_CHANGE_SERVICE FLOW.indication
7) MAC_CHANGE_SERVICE FLOW.response
8) MAC_CHANGE_SERVICE FLOW.confirmation
An existing connection may change characteristics (e.g., bandwidth requirement) of various criteria. The primitives in 5), 6) 7) and 8) above have the same semantics and effect of receipt of the CREATE primitive.
9) MAC_TERMINATE_SERVICE FLOW.request
* Function: Termination of connection is requested by a CS side of a BS or SS.
* Semantics:
MAC_TERMINATE_SERVICE FLOW.request
(
SFID
* Creation Timing: The present primitive is created when the CS of the BS or the SS requests to terminate a connection.
* Effect of Receipt: Creation in SS side—MAC passes a request to a MAC entity in the BS via a dynamic service deletion request (DSD-REQ) message and the BS terminates a connection after examination of the validity of the request. Creation in BS side—Validity of request is already decided and the BS MAC informs the SS of the validity by sending the DSD-REQ message.
10) MAC_TERMINATE_SERVICE FLOW.indication
* Function: A non-initiating MAC entity requests to terminate a connection corresponding to a DSD-REQ message.
* Semantics:
MAC_TERMINATE_SERVICE FLOW.request
(
SFID
)
* Creation Timing: The present primitive is created when receiving a DSD-REQ message to terminate a connection or if necessary to terminate a connection by any reason.
* Effect of Receipt: The BS checks validity of a request. A receiving CS returns a MAC_TERMINATE_SERVICE FLOW.response primitive and erases the SFID.
11) MAC_TERMINATE_SERVICE FLOW.response
* Function: The present primitive is a response to a request to terminate a connection.
* Semantics:
MAC_TERMINATE_SERVICE FLOW.request
(
SFID,
response code,
)
* Creation Timing: The present primitive is created when the CS receives the MAC_TERMINATE_SERVICE FLOW.indication from the MAC.
* Effect of Receipt: The MAC sends a message to an initiating side via a DSD-RSP message.
12) MAC_TERMINATE_SERVICE FLOW.confirmation
Function: A convergence entity is made to confirm that a requested connection is terminated.
* Semantics:
MAC_TERMINATE_SERVICE FLOW.request
(
SFID,
response message
)
* Creation Timing: The present primitive is created when the CS receives the MAC_TERMINATE_SERVICE FLOW.indication from the MAC.
* Effect of Receipt: A convergence entity is informed that a connection is terminated. The same CID is not used anymore for data transfer.
13) MAC_DATA.request
* Function: The present primitive defines a data transfer to a MAC entity from a CS SAP.
* Semantics:
MAC_DATA.request
(
Connection ID,
length,
data,
discard-eligible flag
)
* Creation Timing: The present primitive is created by the CS each time a MAC SDU is transferred to a peer entity.
* Effect of Receipt: A MAC entity processes the MAC SDU through the MAC and passes an appropriately formatted PDU to a PHY convergence sublayer.
14) MAC_DATA.indication
* Function: The present primitive defines a data transfer from a MAC entity to the CS.
* Semantics:
MAC_DATA.incication
(
Connection ID,
length,
data,
reception status
)
* Creation Timing: The present primitive is created each time a MAC SDU is transferred to a peer convergence entity.
* Effect of Receipt: Independent of a content or validity of the MAC SDU. A selection of the CS is decided by the CID with which the MAC SDU is sent.
A media independent handover (MIH) function will now be explained in detail as follows. The MIH is placed below an IP layer and facilitates a handover handling process using a trigger event and an input value from a second layer (Layer 2), such as information of other networks and the like. The MIH can include input values based on user policy and configuration that can influence the handover process. General interfaces are defined between the MIH function and a third layer (Layer 3) entity such as a Mobile IP and an SIP. These interfaces provide information about a first layer (Layer 1) or physical layer (PHY), the second layer (Layer 2) (MAC layer) and mobility management. The MIH acquires information about lower layers and networks with the help of the event and information services. Hence, the MIH function should be placed in a higher layer to monitor and control statuses of other links within the mobile subscriber station.
FIG. 4 is a diagram of functional entities and transport protocols of a terminal including an MIH function and a network. Dotted lines indicate a primitive, an event trigger and the like. FIG. 5 is an exemplary diagram of a broadband wireless access network system (IEEE 802.16) in a protocol stack considering MIH. A stack model shown in FIG. 5 is equivalently applicable to a base station and a mobile subscriber station. However, the mobile subscriber station, which should consider a multi-stack terminal in multi-mode, has a configuration that includes parts shown in the drawing.
A Convergence Sublayer (CS) of an IEEE 802.16 interface in a broadband wireless access system will be explained as follows. A service-specific CS is placed above a MAC CPS and uses a service provided by the MAC CPS via a MAC SAP. The CS performs the Foll owing functions: 1) Receiving a higher PDU from a higher layer; 2) Classifying PDUs of a higher layer; 3) Handling PDUs of a higher layer according to classification (if requested); 4) Delivering CS PDUs to a corresponding MAC SAP; and 5) Receiving CS PDUs from a peer entity.
According to current CS regulations, two types of CSs are provided, i.e., an asynchronous transfer mode (ATM) and a packet CS. Other CSs may be provided in the future. The packet CS is placed above the IEEE 802.16 MAC CPS. Moreover, the packet CS performs the following functions using the services of a MAC: 1) Classifying a higher layer protocol PDU by corresponding access; 2) Suppressing payload header information (options); 3) Delivering CS PDU as a result to a MAC SAP associated with a service flow to enable a transfer to a Peer MAC SAP; 4) Receiving a CS PDU from a Peer MAC SAP; and 5) Reconfiguring suppressed payload header information (option).
A transmitting side CS delivers a MAC SDU to a MAC SAP. A MAC delivers the MAC SDU to a peer MAC SAP according to QoS, separation, connection and other transfer functions associated with a service flow of a specific access. A receiving side CS receives the MAC SDU from the peer MAC SAP and then delivers it to an entity of a higher layer.
A Packet CS is used in transferring all packet-oriented protocols such as IP (Internet Protocol), PPP (point-to-point protocol), IEEE 802.3 (Ethernet) and the like.
FIG. 6 is a diagram of a MAC SDU format. Referring to FIG. 6, a PDU of a higher layer is classified and should be quickly included in the MAC SDU as related to a specific MAC access. In case that a PHS (payload header suppression) rule is defined for the related access, the MAC SDU should include a PHSI (payload header suppression index) field having an 8-bit length.
Classification is a process according to a MAC SDU that is mapped to a specific access for transfer between MAC peers. The mapping process relates the MAC SDU to a specific access and a relationship is established using a service flow characteristic of the specific access. By this process, the MAC SDU is able to be delivered together with a corresponding QoS constraint.
A classifier is a group of consistency references applied to each transport packet of a broadband wireless access communication network. The classifier is configured with a partial packet consistency reference of a specific protocol (e.g., IP address of a called party), a classifier priority and a reference for a CID. If one packet coincides with a specific packet consistency reference, the corresponding packet is delivered to an SAP to be delivered on an access defined by the CID. Optionally, each specific classification function is implemented (e.g., IPv4 based classification). A service flow characteristic of the access provides a QoS for a corresponding packet.
As several classifiers are able to refer to the same service flow, classifier priority is used in designating a sequence for applying classifiers to packets. Since patterns used by the classifiers may overlap each other, a clear sequence should be designated. In designating the sequence, unique priority is unnecessary. Yet, the sequence designation should be carefully conducted within the classifier priority to prevent vagueness in classification. A downlink classifier is transmitted by a base station, wherein the base station conducts the classifier's application to a packet. An uplink classifier is applied by a mobile subscriber station. FIG. 7 and FIG. 8 show the above-explained mapping.
A procedure for Service Flow Creation will now be explained as follows. A mobile subscriber station having completed a network entry procedure enters a service flow registration procedure between a base station and a terminal for data delivery. Service flow includes a service flow identifier (SFID) identifying a corresponding service flow between the base station and the mobile subscriber station, a connection identifier (CID) identifying a connection for delivering service flow traffic, a quality of service (QoS) parameter indicating a quality of the service flow, and the like.
FIG. 9 is a diagram of a procedure for creating a service flow according to a request made by a mobile subscriber station. FIG. 10 is a diagram of a procedure for creating a service flow according to a request made by a base station. Service flow is created by a MAC management message exchange between a mobile subscriber station and a base station according to a request made by the mobile subscriber station or the base station.
Referring to FIG. 9, when a mobile subscriber station requests creation of a service flow, the mobile subscriber station requests service flow creation having a specific quality of service via a dynamic service addition request (DSA-REQ) message. A base station then delivers approval or rejection of the service flow creation to the mobile subscriber station via a dynamic service addition response (DSA-RSP) message. If the service flow creation is approved, the base station grants a service flow identifier (SFID) and a connection identifier (CID) to the corresponding service flow to create the service flow between the mobile subscriber station and the base station. After completion of the service flow creation, the mobile subscriber station and the base station exchange user data via the corresponding service flow.
Referring to FIG. 10, when a base station requests creation of a service flow, the base station requests service flow creation having a specific quality of service via a DSA-REQ message and delivers an SFID and a CID to a mobile subscriber station. The mobile subscriber station having received the DSA-REQ message delivers approval or rejection of the service flow creation to the base station via a DSA-RSP message. After completion of the service flow creation, the mobile subscriber station and the base station exchange user data via the corresponding service flow.
FIG. 11 is a flowchart of a MAC SAP event and a MAC event for connection creation. FIG. 12 is a flowchart of a real MAC event associated with a MAC SAP event for a connection change. FIG. 13 is a flowchart of a MAC SAP event and a MAC event for a connection deletion. FIGS. 11 to 13 show mutual actions between MAC service primitives and DSx messages, respectively.
However, in the related art communication method for MIH, if a newly established MIH layer attempts to send a message to a remote MIH entity via a radio section, a communication method between MIH entities is not determined. Hence, message transactions between the MIH entities are impossible.